<h2>Play with this demo</h2>
<p>
In this Activity, you can : 
<ul>
  <li> start an AsyncTask and see the progress ;
  <li> cancel a started AsyncTask ;
  <li> start an AsyncTask, rotate the device and observe that UI is updated as expected ;
  <li> simulate a memory leak : rotate the device and start an AsyncTask, repeat 30 times. You can see memory is getting 
  lower and lower after each rotation.
</ul>
</p>

<p>
Read below to learn more.
</p>

<h2>Advanced AsyncTask usage 1/2. </h2>

This Activity uses an AsyncTask declared as a static inner class. <br>

<h3>The AsyncTask and Activity life cycle</h3>
<p>
The advantage of a static inner class (exactly the same as a proper public class in a different file) is that 
the AsyncTask doesn't hold any invisible reference to the activity. Instead, the AsyncTask will be given an explicit reference to the current Activity.
Thus, we have more control over this reference.
</p>

<p>
In this activity, we used a workaround to tie the Activity life cycle to the same instance of the AsyncTask. 
If you start an AsyncTask, rotate the device and don't start any new AsyncTask, the Activity will be destroyed and a new instance will be created.
As before, the AsyncTask will continue its life until it completes. But we re-link the new instance of the Activity to the AsyncTask. 
</p>

<p>
After a new instance of the Activity is created, its UI will be updated by the formerly created AsyncTask.
</p>

<p>
The advantage of this technique is that an AsyncTask instance holds a reference to the most recent Activity instance. It doesn't
prevent garbage collection of the Activity instances that are not displayed anymore. 
</p>

<p>
The technique proposed here uses the method : <tt>getLastCustomNonConfigurationInstance</tt>. This method is only
available in support classes. In the "normal" Android SDK, you would use the method <tt>getLastNonConfigurationInstance</tt> but this 
method is deprecated as it used internally by the Loader Framework of Android and is not available in the support library class FragmentActivity.
This method is not a general solution, as it depends on the Activity class you use (with support or not).
</p>

<h3>Memory leak issue</h3>

<p>
As we said, to limit the risk of memory leak, we propose an implementation so that the same AsyncTask instance can hold a reference only 
to one single instance of the outer Activity. This is better than the basic AsyncTask example. 
</p>

<p>
<em>Nevertheless, this produces a memory leak if you start several AsyncTasks, not as important as the previous demo Activity but still a memory leak.</em>
</p>

<p>
When AsyncTasks are executed, they are passed to an ExecutorService <a href="http://stackoverflow.com/q/4068984/693752"> (that used to be single-threaded prior to DONUT release, multi-threaded between DONUT and 
HONEYCOMB, and back to single-threaded after HONEYCOMB included).</a> This means that the ExecutorService is holding a reference on all your AsyncTask instances.
As in every AsyncTask we hold a reference to an Activity, the Activity can't be garbage collected as long as the AsyncTask is still queued
by the ExecutorService. This causes a memory leak.
</p>

<p>
To simulate the problem, start an AsyncTask, rotate the device, and repeat this process. After 30-40 times, you will get an <tt>OutOfMemoryException</tt>.
It takes more time as some AsyncTask terminate their live and allow garbage collection of some activities, but they can't cope if you start AsyncTasks 
at a rapid pace.
</p>

<hr>
We propose a last workaround to memory issue management in the next example, by using WeakReferences.
